home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 7 / Apprentice-Release7.iso / Environments / Small Eiffel 0.4.8 / misc / Eiffel.FAQ < prev    next >
Text File  |  1997-01-03  |  48KB  |  1,389 lines
  1. Newsgroups: comp.lang.eiffel,comp.answers,news.answers
  2. Subject: comp.lang.eiffel Frequently Asked Questions (FAQ)
  3. From: Conrad Taylor <conradt@comm.mot.com>
  4. Reply-To: conradt@comm.mot.com
  5. Followup-To: comp.lang.eiffel
  6. Approved: news-answers-request@mit.edu
  7. Archive-name: comp.lang.eiffel
  8. Posting-Frequency: approximately monthly
  9. Last-modified: 3 Sep 1996
  10.  
  11. EIFFEL: FREQUENTLY ASKED QUESTIONS
  12. ----------------------------------
  13.  
  14. This question-and-answer list is posted monthly to the Usenet 
  15. newsgroups comp.lang.eiffel, comp.answers and news.answers.
  16.  
  17. Please send corrections, additions and comments to Conrad Taylor 
  18. (conradt@sc.comm.mot.com).
  19.  
  20. This information is abstracted and condensed from the posts of many 
  21. contributors to comp.lang.eiffel, supplemented by information from 
  22. vendors. No guarantees are made regarding its accuracy.
  23.  
  24. This compilation is by Conrad Taylor. Distribution over the Internet or 
  25. by electronic mail is unrestricted. Other use requires my permission.
  26.  
  27. You can receive the latest copy by anonymous file transfer from:
  28.  
  29.    ftp://ftp.cm.cf.ac.uk/pub/eiffel/eiffel-faq
  30.    ftp://rtfm.mit.edu/pub/usenet/news.answers/eiffel-faq
  31.  
  32. or by sending an email message to archive-server@cm.cf.ac.uk with this 
  33. message body:
  34.  
  35.    send comp.lang.eiffel eiffel-faq
  36.  
  37. ----------
  38.  
  39. CONTENTS
  40.  
  41. Changes since the last posting:
  42.  
  43. What's New:
  44.  
  45.    N01) EiffelWorld Online
  46.  
  47. Frequently Asked Questions:
  48.  
  49.    Q01) What is Eiffel?
  50.    Q02) Where did Eiffel come from?
  51.    Q03) What Eiffel products are available?
  52.    Q04) Is Eiffel available for free or as shareware?
  53.    Q05) Is there an archive of the comp.lang.eiffel newsgroup?
  54.    Q06) What is Sather? How does it compare to Eiffel?
  55.    Q07) What books are available for learning about Eiffel?
  56.    Q08) Are any magazines or newsletters available concerning Eiffel?
  57.    Q09) Where can I find Eiffel on the World-Wide-Web?
  58.    Q10) Where can I get an Eiffel editor or emacs-mode?
  59.    Q11) What is BON?
  60.    Q12) How large are typical Eiffel executables?
  61.    Q13) Are there standards for the Eiffel language?
  62.    Q14) How fast do Eiffel applications run?
  63.    Q15) Are there any Eiffel user groups?
  64.    Q16) Where can I get Eiffel products and services?
  65.    Q17) Are there any conferences for Eiffel users?
  66.    Q18) Why do most Eiffel implementations compile to C?
  67.  
  68. Language Issues:
  69.  
  70.    L01) What features does Eiffel have?
  71.    L02) What changes have been made to the Eiffel language definition?
  72.    L03) What libraries come with Eiffel?
  73.    L04) What's the big deal about preconditions and postconditions?
  74.    L05) Please explain and discuss covariance vs. contravariance.
  75.    L06) Is it true that there are "holes" in the Eiffel type system?
  76.    L07) Is there support for concurrency in Eiffel?
  77.    L08) Why doesn't Eiffel allow function overloading?
  78.    L09) Why are there no procedural types in Eiffel?
  79.    L10) Why are there no class attributes in Eiffel?
  80.    L11) How can I call the parent-class version of a redefined 
  81.         routine?
  82.    L12) Where can I find a comparison between Eiffel and C++?
  83.    L13) Are there any destructors in Eiffel?
  84.  
  85. N01)  EiffelWorld Online
  86.  
  87. We are pleased to announce that EiffelWorld is now 
  88. available on-line! This is your first quarterly reminder 
  89. to visit the EiffelWorld Online magazine at
  90.  
  91. http://www.eiffel.com/doc/eiffelworld/5.2
  92.  
  93.  
  94. ----------
  95.  
  96. Q01)   What is Eiffel?
  97.  
  98. Eiffel is an advanced object-oriented programming language that 
  99. emphasizes the design and construction of high-quality and reusable 
  100. software.
  101.  
  102. Eiffel is not a superset or extension of any other language. Eiffel 
  103. strongly encourages OO programming and does not allow dangerous 
  104. practices from previous generation languages although it does 
  105. interface to other languages such as C and C++. Eiffel supports the 
  106. concept of "Design by Contract" to improve software correctness.
  107.  
  108. Beyond the language aspect Eiffel may be viewed as a method of 
  109. software construction. Eiffel is an excellent vehicle for software 
  110. education, including for a first programming course.
  111.  
  112. ----------
  113.  
  114. Q02)   Where did Eiffel come from?
  115.  
  116. Eiffel was created by Bertrand Meyer and developed by his company, 
  117. Interactive Software Engineering (ISE) of Goleta, CA.
  118.  
  119. Dr. Meyer borrowed on his extensive experience with OOP, particularly 
  120. with Simula. He also added in important concepts from his academic 
  121. work on software verification and computer language definition.
  122.  
  123. Eiffel's design addresses many practical concerns that software 
  124. engineers face when creating complex software. Eiffel has evolved 
  125. continually since its conception on September 14, 1985 and its first 
  126. introduction in 1986.
  127.  
  128. Eiffel is named after Gustave Eiffel, the engineer who designed the 
  129. Eiffel Tower.
  130.  
  131. ----------
  132.  
  133. Q03)   What Eiffel products are available?
  134.  
  135. Commercial Eiffel compilers, libraries and tools are available from 
  136. the following vendors and their resellers:
  137.  
  138.   Interactive Software Engineering Inc (ISE Eiffel)
  139.   Tower Technology Corporation (TowerEiffel)
  140.   SIG Computer GmbH (Eiffel/S)
  141.   Jan Willamowius (Eiffel adaption of SNiFF+ Programming Environment)
  142.  
  143. The following platforms are supported by one or more of the above 
  144. vendors:
  145.  
  146.   PC: DOS, OS/2, Windows 3.1, Windows 95, Windows NT, PC Unix 
  147.     (Interactive, SCO, and ESIX), Nextstep, Linux
  148.   OTHER HARDWARE: Sparc (SunOS & Solaris), NeXTStep, HP9000, DEC 5xxx, 
  149.     Sony News, DG Aviion, DEC Alpha OSF-1, DEC OpenVMS, RS6000, 
  150.     Pyramid, QNX, Silicon Graphics, Macintosh (Motorola & PowerPC)
  151.  
  152. Special offers are available on many of these products for personal or 
  153. educational use.
  154.  
  155. Further information about these products is available from the vendors 
  156. by email and on the world-wide-web.
  157.  
  158. See Q16 for contact details and websites.
  159.  
  160. ----------
  161.  
  162. Q04)   Is Eiffel available for free or as shareware?
  163.  
  164. All of Eiffel - All graphical - All for free!
  165.  
  166. FREE EIFFEL FOR WINDOWS is a free version of ISE's acclaimed Melting Ice
  167. Technology compiler and environment for Eiffel. No strings attached -- it's
  168. FREE!
  169.  
  170.        FREE EIFFEL FOR WINDOWS is now fully graphical, showing the power of
  171.        the EiffelBench set of advanced development tools for fast
  172.        compilation, documentation, browsing, debugging and much more!
  173.  
  174.        The earlier text-based environment is still available, but we think
  175.        you'll want to try the graphical environment right away!
  176.  
  177. Technical support for FREE EIFFEL FOR WINDOWS is available. Details are
  178. included in the delivery, or contact us.
  179.  
  180. Also of interest
  181.  
  182. Upgrade to Personal or Professional Eiffel for Windows for an unbeatable
  183. price and get printed documentation, more tools, more libraries, support and
  184. more.
  185.  
  186. Also note our highly affordable ISE Eiffel for Linux , supporting the entire
  187. set of ISE Eiffel mechanisms for the fastest growing version of Unix. And of
  188. course ISE Eiffel is available for the major platforms in the industry, from
  189. Unix to VMS with more to come.
  190.  
  191. Getting familiar with the environment
  192.  
  193. On-line documentation is included in the delivery. But please do us a favor:
  194. if you are new to ISE Eiffel, please take a few minutes (now or later, but
  195. before you start using the environment) to consult the on-line introduction
  196. to EiffelBench. The powerful interaction techniques of ISE Eiffel are
  197. innovative and have been known to startle newcomers. We are sure you will
  198. love them, but first you must read about the essential ideas.
  199.  
  200. Downloading FREE EIFFEL FOR WINDOWS
  201.  
  202. Note: if you want the graphical version (who doesn't?) do NOT download it
  203. from SimTel or any of the other sites. At the moment only ISE's site has
  204. FREE GRAPHICAL EIFFEL FOR WINDOWS.
  205.  
  206. Be sure to choose the version for the appropriate variant of Windows, as
  207. listed below: Windows 95, Windows NT or Windows 3.1. The Windows 3.1 version
  208. will NOT work under 95 or NT.
  209.  
  210. To download the FREE GRAPHICAL EIFFEL FOR WINDOWS, go to the ISE Web Site:
  211.  
  212.   From the WWW:  http://www.eiffel.com
  213.   Directly from FTP:  ftp.eiffel.com
  214.  
  215. SIG Computer's "Eiffel/S 1.3s" is a shareware version of their Eiffel 
  216. compiler for DOS and Unix and is available by FTP from SimTel mirror 
  217. sites in SimTel/msdos/eiffel, or from the UWCC archive 
  218. at
  219.  
  220.   ftp//ftp.cm.cf.ac.uk/pub/Eiffel/SIG/Eiffel-S-1.3/  
  221.  
  222. The EON Eiffel compiler is shareware under MS-DOS and Linux, and a 
  223. beta-test version is available from
  224.  
  225.   ftp://ftp.demon.co.uk/pub/eiffel/eon-eiffel/
  226.  
  227. SmallEiffel is a free Eiffel compiler distributed under the terms of 
  228. the GNU General Public License as published by the Free Software 
  229. Foundation.  You can download SmallEiffel at
  230.  
  231.   ftp://ftp.loria.fr/pub/loria/genielog/SmallEiffel
  232.  
  233. The following Eiffel archive sites allow anonymous file transfer:
  234.  
  235. ftp://ftp.tu-clausthal.de/pub/atari/languages/eiffel/vici_102.lzh
  236.   The Atari ST interpreter referred to above.
  237.  
  238. ftp://ftp.cm.cf.ac.uk/pub/eiffel
  239.   University of Wales. Contains the latest version of this FAQ, plus 
  240.   the front-end parser (ep) and various public domain classes. To 
  241.   contribute, contact Ted Lawson (ted@cm.cf.ac.uk).
  242.  
  243. ftp://ftp.fu-berlin.de/pub/unix/languages/heron
  244.   This is an Eiffel front-end parser (HERON) in the public domain, 
  245.   created by Burghardt Groeber and Olaf Langmack of the Freie 
  246.   Universitaet in Berlin.
  247.  
  248. ftp://ftp.informatik.uni-stuttgart.de/pub/eiffel
  249.   Falkultaet Informatik der Universitaet Stuttgart, Germany. Contains 
  250.   a compiler generator, several encapsulations, a pretty-printer for 
  251.   Eiffel/S, and some utility classes. To contribute, contact Joerg 
  252.   Schulz (schulz@adam.informatik.uni-stuttgart.de).
  253.  
  254. ftp://utarlg.uta.edu/CSE/EIFFEL
  255.   UT-Arlington, USA. Contains some code from Eiffel Outlook back 
  256.   issues.
  257.  
  258. SIG Computer produces a CD-ROM containing most of the available 
  259. freeware, shareware and public domain Eiffel material.
  260.  
  261. ----------
  262.  
  263. Q05)   Is there an archive of the comp.lang.eiffel newsgroup?
  264.  
  265. Yes, at the following FTP sites:
  266.  
  267.   ftp://wuarchive.wustl.edu/usenet/comp.lang.eiffel/
  268.  
  269. and on the WWW at http://www.cm.cf.ac.uk/CLE/
  270.  
  271. ----------
  272.  
  273. Q06)   What is Sather? How does it compare to Eiffel?
  274.  
  275. Sather is an OO language, originally patterned after Eiffel but now 
  276. very different, created at ICSI of Berkeley, CA.
  277.  
  278. Sather does not support Design by Contract, but has some other 
  279. interesting features. See the usenet newsgroup comp.lang.sather.
  280.  
  281. ----------
  282.  
  283. Q07)   What books are available for learning about Eiffel?
  284.  
  285. The classic text for learning about Eiffel (and OO programming in 
  286. general) is Dr. Meyer's "Object Oriented Software Construction". 
  287. Although the language has evolved significantly since the book was 
  288. published, the presentation of the basic problems and solutions which 
  289. motivate the OO mind set are still quite compelling. This is the book 
  290. to get if you are new to the object-oriented world (Prentice Hall, 
  291. ISBN 13-629031-0). Available in French as "Conception et Programmation 
  292. par Objets" (90/10 InterEditions, ISBN 2-7296-0272-0) and in German as 
  293. "Objektorientierte Softwareentwicklung (Hanser, ISBN 3-446-15773-5).
  294.  
  295. Also by Dr. Meyer, "Eiffel: The Language", combines an introduction to 
  296. Eiffel, the language reference, and a good deal of philosophy into its 
  297. 600 pages. This is a rigorous and comprehensive book which some 
  298. readers may find heavy going despite Dr. Meyer's clarity of 
  299. expression. It is the definitive language reference, and essential 
  300. reading for all serious Eiffel users. Get the second or later printing 
  301. (same ISBN), which includes many corrections and changes (there is not 
  302. a second edition, and none is currently underway) (Prentice Hall, ISBN 
  303. 13-247925-7). Available in French as "Eiffel, le langage" (94/10 
  304. InterEditions, ISBN 2-7296-0525-8).
  305.  
  306. Dr. Meyer and Jean-Marc Nerson have edited "Object-Oriented 
  307. Applications". It includes an introduction to Eiffel technology 
  308. followed by seven in-depth descriptions of large applications written 
  309. in Eiffel. (Prentice Hall, ISBN 13-013798-7)
  310.  
  311. Robert Switzer has written "Eiffel: An Introduction". This is a very 
  312. clear and concise Eiffel primer, with many code fragments and two 
  313. substantial Eiffel applications. (Prentice Hall, ISBN 13-105909-2). 
  314. Available in French as "Introduction a Eiffel" (Masson, ISBN 
  315. 2-225-84-656-1)
  316.  
  317. ISE distributes a set of 6 video lectures entitled "Object-Oriented 
  318. Software Construction", taught by Bertrand Meyer. These provide an 
  319. overall introduction to the method and use ISE Eiffel 3 to illustrate 
  320. the concepts.
  321.  
  322. Frieder Monninger's book "Eiffel: Objektorientiertes Programmieren in 
  323. der Praxis" is a very down-to-earth Eiffel handbook in German. (Heise, 
  324. ISBN 3-88229-028-5).
  325.  
  326. Bertrand Meyer's "Reusable Software: The Base Object-Oriented 
  327. Component Libraries" (Prentice Hall, ISBN 0-13-245499-8, about 530 
  328. pages) describes principles of library design and the taxonomy of 
  329. fundamental computing structures. Serves as a manual for the 
  330. EiffelBase libraries.
  331.  
  332. Bertrand Meyer's "An Object-Oriented Environment: Principles and 
  333. Application" (Prentice Hall, ISBN 0-13-245507-2, 240 pages) describes 
  334. the ISE EiffelBench environment as well as the "Melting Ice" 
  335. compilation technology and the EiffelBuild GUI application builder.
  336.  
  337. Richard Wiener's "Software Development Using Eiffel: There can be life 
  338. other than C++" (Prentice-Hall, ISBN 0-13-100686-X) is a useful book 
  339. (full of serious code samples) for those with a grounding in another 
  340. OO language.
  341.  
  342. A book by Kim Walden and Jean-Marc Nerson, "Seamless Object-Oriented 
  343. Software Architecture: Analysis and Design of Reliable Systems", 
  344. describes the BON method in detail (Prentice Hall, ISBN 
  345. 0-13-031303-3).
  346.  
  347. Pete Thomas and Ray Weedon's "OO Programming in Eiffel" is a very 
  348. comprehensive Eiffel tutorial and textbook, with a solid "Abstract 
  349. Data Type" approach (Addison-Wesley, ISBN 0-201-59387-4).
  350.  
  351. Another book called "OO Programming in Eiffel" is by Robert Rist and 
  352. Robert Terwilliger, and is a textbook with an emphasis on design. 
  353. (Prentice-Hall, ISBN 0-13-205931-2).
  354.  
  355. Bertrand Meyer's "Object Success" is a manager's guide to object 
  356. orientation, its impact on the corporation and its use for 
  357. re-engineering the software process (Prentice-Hall, ISBN 
  358. 0-13-192833-3).
  359.  
  360. Macmillan publishes John Tyrrell's inexpensive and very approachable 
  361. textbook "Eiffel Object-Oriented Programming" (ISBN 0-333-64554-5).
  362.  
  363. "Object-Oriented Software Engineering with Eiffel"
  364. By Jean-Marc Jezequel, Addison-Wesley Eiffel in Practice Series
  365. ISBN 0-201-63381-7 * Paperback * 368 pages * ) 1996
  366.  
  367. There is also a white paper titled 'Eiffel: A Manager's Perspective' 
  368. which provides a quick introduction to Eiffel and the benefits it 
  369. brings to the software development process. For a free copy, send your 
  370. name and postal address to tower@twr.com
  371.  
  372. ----------
  373.  
  374. Q08)   Are any magazines or newsletters available concerning Eiffel?
  375.  
  376. Eiffel Outlook is a bi-monthly journal devoted to Eiffel, published 
  377. since 1991. Topics cover all areas of interest to the Eiffel 
  378. community.
  379.  
  380. Subscriptions, trial subscriptions and back issues are available from:
  381.  
  382.    SIG Computer in Germany
  383.    Everything Eiffel in the UK & France
  384.    Simon Parker in Ireland
  385.    IMSL in Japan
  386.    Enea Data in Sweden
  387.    Tower Technology in the USA and all other countries
  388.  
  389. Details are available at <http://www.cm.cf.ac.uk/Tower/Outlook.html> 
  390. or by sending email to <outlook@twr.com>.
  391.  
  392. ISE produces a newsletter "Eiffel World". Subscriptions are free 
  393. (email your request to info@eiffel.com). Individual copies are 
  394. available from:
  395.  
  396.    Cybertech in Argentina
  397.    Class Technology in Australia
  398.    Jay-Kell Technologies in Canada
  399.    SOL in France
  400.    SIG Computer in Germany
  401.    Eiffel Ireland in Ireland
  402.    Etnoteam in Italy
  403.    Information & Math Science Lab 
  404.    Software Research Associates in Japan
  405.    Chromasoft in Mexico
  406.    Science OO Products & Systems in the Netherlands
  407.    Objective Methods in New Zealand
  408.    Ruperez & Associates in Spain
  409.    Enea Data in Sweden
  410.    Abstraction in Switzerland
  411.    Everything Eiffel in the UK
  412.  
  413.    Also, EiffelWorld is now available on-line! This is your first 
  414.    quarterly reminder to visit the EiffelWorld Online magazine at
  415.  
  416.    http://www.eiffel.com/doc/eiffelworld/5.2
  417.  
  418. If you're interested in Software Design Patterns you may like to 
  419. subscribe to the Eiffel Patterns mailing list. Send email to:
  420.  
  421.    e-patterns-request@cbr.dit.csiro.au
  422.  
  423. ----------
  424.  
  425. Q09)   Where can I find Eiffel on the World-Wide-Web?
  426.  
  427. An Eiffel home page is held on the University of Wales College of 
  428. Cardiff's server at http://www.cm.cf.ac.uk/CLE/. Vendor websites are 
  429. listed in Q16.
  430.  
  431. ----------
  432.  
  433. Q10)   Where can I get an Eiffel editor or emacs-mode?
  434.  
  435. Franck Arnaud's Eiffel extension to the Windows/WindowsNT programmers 
  436. editor Codewright from Premia allows you to see Eiffel code in colour, 
  437. has smart indenting and a few templates. Available by anonymous FTP 
  438. from ftp://ftp.cm.cf.ac.uk/pub/eiffel/tools/cweiffel.zip
  439.  
  440. The WINEDIT shareware programmer's editor offers colour syntax 
  441. highlighting, works with Eiffel/S under MS-Windows, and is available 
  442. from: 
  443. ftp://src.doc.ic.ac.uk/computing/systems/ibmpc/windows3/programr/we-30d.zip
  444. and ftp://gatekeeper.dec.com/.f/micro/msdos/win3/programr/we-30d.zip
  445.  
  446. Alan Philips' free Programmers File Editor also works with Eiffel/S 
  447. under MS-Windows, has templates but not syntax highlighting, available 
  448. from ftp://ftp.demon.co.uk/pub/ibmpc/windows/editors/pfe0507.zip
  449.  
  450. Tower Technology Corporation supplies an Eiffel 3 emacs mode that 
  451. supports syntax-directed highlighting, auto-indentation and is easily 
  452. customized for font use, color and indentation amounts. It comes as 
  453. part of the TowerEiffel system, but is also available free for anyone 
  454. who requests it. Send email to elisp@atlanta.twr.com to get the latest 
  455. version.
  456.  
  457. ----------
  458.  
  459. Q11)   What is BON?
  460.  
  461. BON ("Business Object Notation") is a method for high-level analysis 
  462. and design, offering a seamless reversible transition to an Eiffel 
  463. implementation. The method emphasizes Design by Contract and 
  464. systematic development.
  465.  
  466. ISE supports BON with its EiffelCASE tool.
  467.  
  468. ----------
  469.  
  470. Q12)   How large are typical Eiffel executables?
  471.  
  472. (How large are typical C executables?)
  473.  
  474. In general, the size of an executable depends on the compiler used. 
  475. Thus, a good Eiffel compiler would produce good C code by removing 
  476. dead code such that a C executable is not smaller than an Eiffel 
  477. executable.  This is true of SmallEiffel and ISE Eiffel compilers.  
  478. Also, I think this is similar for others like Tower Eiffel and SIG 
  479. Eiffel compilers.
  480.  
  481. Interestingly, Eiffel applications seem to grow less rapidly as new 
  482. capabilities are added. Reuse does help out tremendously in this 
  483. regard. A good Eiffel compiler allows large applications to be smaller 
  484. than equally functional applications written in C.
  485.  
  486. Note that leaving assertion checking in the code increases the size of 
  487. applications a lot. Despite this, many of us prefer that they remain 
  488. throughout development. Some even deliver a PRECONDITIONS-only version 
  489. of their applications to their early customers.
  490.  
  491. ----------
  492.  
  493. Q13)   Are there standards for the Eiffel language?
  494.  
  495. The definition of the Eiffel language is in the public domain. This 
  496. definition is controlled by NICE, the Non-profit International 
  497. Consortium for Eiffel. This means that anyone or any company may 
  498. create a compiler, interpreter, or whatever having to do with Eiffel. 
  499. NICE reserves the right to validate that any such tool conforms to the 
  500. current definition of the Eiffel language before it can be distributed 
  501. with the Eiffel trademark. (i.e. advertised as an "Eiffel" compiler.)
  502.  
  503. The Eiffel trademark is owned and controlled by NICE. NICE is using 
  504. Bertrand Meyer's book, "Eiffel: The Language" (2nd Printing), as the 
  505. initial definition of the language.
  506.  
  507. The NICE board of directors for 1995 consists of Christine Mingins 
  508. (chair), Bertrand Meyer (treasurer), Simon Parker (secretary) and Paul 
  509. Johnson.
  510.  
  511. In June 1995 NICE published the first version (called "Vintage 95") of 
  512. the Eiffel Library Standard. Those parts of an Eiffel application that 
  513. use only the standard classes and features should run with minimal 
  514. change on any compiler supporting ELS-95.
  515.  
  516. NICE (Nonprofit International Consortium for Eiffel)
  517. 45 Hazelwood
  518. Shankill
  519. Co Dublin
  520. Republic of Ireland
  521. TEL: +353 1 282 3487
  522. email: nice@atlanta.twr.com
  523.  
  524. ----------
  525.  
  526. Q14)   How fast do Eiffel applications run?
  527.  
  528. Early versions of Eiffel were slow. Recent implementations have 
  529. improved dramatically. However, to achieve maximum performance under 
  530. any Eiffel implementation, run-time assertion monitoring must be 
  531. switched off. (But see Q12 on when to switch assertions on or off.)
  532.  
  533. It's hard to generalise, but compared to C++, simple 
  534. computation-intensive applications will run perhaps 15% slower. Large 
  535. applications are often dominated by memory management rather than 
  536. computation. ISE recently demonstrated that by simply adding a call to 
  537. the garbage collector's "full-collect" routine at a time when there 
  538. were known to be few live objects, performance became dramatically 
  539. faster than a corresponding C++ version.
  540.  
  541. ----------
  542.  
  543. Q15)   Are there any Eiffel user groups?
  544.  
  545. International Eiffel User Group
  546. Darcy Harrison - Attention: IEUG
  547. ISE Inc.
  548. 270 Storke Road, Suite 7
  549. Goleta, CA 93117, USA
  550. TEL (805) 685-1006
  551. FAX (805) 685-6869
  552. darcyh@eiffel.com
  553.  
  554. UK & Ireland Eiffel Interest Group (currently inactive)
  555.  
  556. GUE, Groupe des Utilisateurs Eiffel (France)
  557. Jean-Marc Nerson
  558. 104 rue Castagnary, 75015 Paris
  559. TEL +33 1 45 32 58 80
  560. FAX +33 1 44 32 58 81
  561. marc@eiffel.fr
  562. (meets every 2 months or so)
  563.  
  564. TowerEiffel User's Group
  565. Private cyberspace mailing list for supported Tower customers with 
  566. meetings coinciding with major OO Conferences and Events.
  567.  
  568. ----------
  569.  
  570. Q16)   Where can I get Eiffel products and services?
  571.  
  572. These vendors, resellers and suppliers of Eiffel training and
  573. consultancy are listed in alphabetical order:
  574.  
  575. Argentina
  576.  
  577. Cybertech
  578. Systens Integration for CIM
  579. Suarez 1281, Third Floor,Apt.A
  580. CP-1288 Buenos Aires
  581. TEL +54 1 28 1950
  582. FAX +54 1 322 1071 or 963 0070
  583.  
  584.  
  585. Australia
  586.  
  587. Class Technology Pty. Ltd.
  588. PO Box 2674
  589. North Sydney NSW 2060
  590. TEL +61 2 9922 7222
  591. FAX +61 2 9922 7703
  592. email info@class.com.au
  593.  
  594.  
  595. Canada
  596.  
  597. Jay-Kell Technologies, Inc.
  598. 48 Lakeshore Road, Suite #1
  599. Pointe Claire, Quebec
  600. Canada H9S 4H4
  601. TEL +51 4 630 1005
  602. FAX +51 4 630 1456
  603.  
  604.  
  605. France
  606.  
  607. SOL
  608. 104 rue Castagnary
  609. 75015 Paris
  610. TEL +33 1 45 32 58 80
  611. FAX +33 1 45 32 58 81
  612. email eiffel@eiffel.fr
  613.  
  614.  
  615. Germany
  616.  
  617. Feinarbeit
  618. Altenbraker Strasse 4
  619. D-12053 Berlin
  620. TEL +49 30 6215827
  621. FAX +49 30 6215863
  622. email langmack@netmbx.netmbx.de
  623.  
  624. SIG Computer GmbH
  625. Zu den Bettern 4
  626. D 35619 Braunfels, Germany
  627. TEL +49 6472 2096
  628. FAX +49 6472 7213
  629. email eiffel@eiffel.de
  630. www http://www.sigco.com/
  631.  
  632. Jan Willamowius
  633. Semperstr. 1
  634. D-22303 Hamburg
  635. Hamburg, Germany
  636. Tel: +49 40-2806209
  637. Email: jan@janhh.shnet.org
  638. WWW: http://swt1.informatik.uni-hamburg.de/~1willamo/dl.html
  639.  
  640.  
  641. Ireland
  642.  
  643. Eiffel Ireland
  644. 45 Hazelwood
  645. Shankill
  646. Co Dublin
  647. TEL +353 1 282 3487
  648. email sparker@eiffel.ie
  649. www http://www.eiffel.ie/Eiffel/
  650.  
  651.  
  652. India
  653.  
  654. Sritech Information Technology
  655. 744/51 2nd Floor
  656. 10 Mian Road, 4th Block
  657. Jayanagar, Bangalore, India 560011
  658. TEL +91 812 640661
  659. FAX +91 812 643608
  660.  
  661.  
  662. Italy
  663.  
  664. EtnoTeam
  665. Via Adelaide Bono Cairoli 34
  666. 20217 Milano
  667. TEL +39 2 261621
  668. FAX +39 2 26110755
  669. email sales@etnomi.it
  670.  
  671.  
  672. Japan
  673.  
  674. Information and Math Science Lab Inc.
  675. 2-43-1, Ikebukuro, Toshima-ku
  676. Tokyo 171
  677. email fushimi@idas.imslab.co.jp
  678. TEL +81 3 3590 5211
  679. FAX +81 3 3590 5353
  680.  
  681. Software Research Associates
  682. 1-1-1 Hirakawo-Cho
  683. Chiyoda-ku Tokyo 102
  684. TEL +81 3 3234 8789
  685. FAX +81 3 3262 9719
  686. email sugita@sra.co.jp
  687.  
  688.  
  689. Mexico
  690.  
  691. Cromasoft SA de CV
  692. Mazatlan 161
  693. Col Condesa, 06140 Mexico
  694. TEL +52 5 286 82 13
  695. FAX +52 5 286 80 57
  696. email claudio@croma.sunmexico.sun.com
  697.  
  698.  
  699. The Netherlands
  700.  
  701. SOOPS
  702. Sarphatistraat 133
  703. NL-1018 GC Amsterdam, The Netherlands
  704. TEL +31 20 525 6644
  705. FAX +31 20 624 6392
  706. email A731CISK@HASARA11.BITNET
  707.  
  708.  
  709. New Zealand
  710.  
  711. Objective Methods Ltd
  712. PO Box 17356 (77 Chamberlain Rd)
  713. Karori, Wellington, New Zealand
  714. TEL +64 4 476 9499
  715. FAX +64 4 476 9237 or 8772
  716. email dkenny@swell.actrix.gen.nz
  717.  
  718.  
  719. Russia
  720. SIG Computer, Germany has a branch office in Moscow.
  721. email eiffel@sigcomp.msk.su
  722.  
  723.  
  724. Spain
  725.  
  726. Eiffel Iberica
  727. Aptdo 1646
  728. 20080 San Sebastian
  729. TEL +34 943 471906
  730. email ean@sc.ehu.es
  731.  
  732. Ruperez & Associates
  733. c/San Bartolome 21, 5F
  734. 20001 San Sebastian
  735. TEL +34 43 461801
  736. email jipferur@si.ehu.es
  737.  
  738.  
  739. Sweden
  740.  
  741. Enea Data
  742. Box 232, Nytorpsvagen 5
  743. S-183 23 Taby
  744. TEL +46 8 792 25 00
  745. FAX +46 8 768 43 88
  746. email eiffel@enea.se
  747.  
  748.  
  749. Switzerland
  750.  
  751. Abstraction                           
  752. 18 Faubourg de l'Hopital              
  753. 2000 Neuchatel                        
  754. TEL +41.38.25.04.93                 
  755. FAX +41.38.259.857                    
  756. email silberstein@clients.switch.ch
  757.  
  758. Objectif Concept       
  759. Passage Cour-Robert 5  
  760. CH 1700 Fribourg       
  761. TEL +41 37 232977      
  762. FAX +41 37 464889      
  763.  
  764.  
  765. United Kingdom
  766.  
  767. Eon Software                          
  768. 19 Stapleton Road                     
  769. Heddington, Oxford OX3 7LX            
  770. TEL +44 865 741452                    
  771. email ian@eonsw.demon.co.uk           
  772.                                       
  773. Everything Eiffel                                                     
  774. 6 Bambers Walk                                                        
  775. Wesham PR4 3DG                                                        
  776. England                                                               
  777. TEL & FAX +44 1772 687525                                             
  778. email rogerb@eiffel.demon.co.uk                                       
  779.  
  780.  
  781. United States of America                                     
  782.  
  783. Interactive Software Engineering, Inc
  784. 270 Storke Road, Suite 7
  785. Goleta, CA 93117
  786. TEL 805-685-1006
  787. FAX 805-685-6869
  788. email info@eiffel.com
  789. www http://www.eiffel.com/
  790.  
  791. Tower Technology Corporation
  792. 1501 Koenig Lane
  793. Austin, TX 78756 USA
  794. TEL 512-452-9455
  795. FAX 512-452-1721
  796. email: tower@twr.com
  797. www http://www.twr.com/
  798.  
  799. ZumaSoft
  800. 6235 Paseo Canyon Drive
  801. Malibu, California 90265, USA
  802. TEL & FAX +1 310 457-6263
  803. email tstevens@netcom.com
  804.  
  805. ----------
  806.  
  807. Q17)   Are there any conferences for Eiffel users?
  808.  
  809. The conferences listed here are not just for Eiffel. Eiffel shares the 
  810. spotlight with other OO languages including C++ and Smalltalk.
  811.  
  812. Feb 26 - 29 1996
  813. TOOLS Europe, Paris France
  814.  
  815. Jul 29 - Aug 2 1996
  816. TOOLS USA, Santa Barbara California
  817.  
  818. TOOLS is the major international conference devoted to the 
  819. applications of OO technology. Other events, such as Eiffel User Group 
  820. meetings or NICE meetings are often held in conjunction with TOOLS.
  821.  
  822. TOOLS Conferences
  823. PO Box 6863, Santa Barbara, CA 93160, USA
  824. TEL (805) 685 1006, FAX (805) 685 6869
  825. email tools@tools.com
  826.  
  827. ----------
  828.  
  829. Q18)   Why do most Eiffel implementations compile to C?
  830.  
  831. By using C as a target language, an Eiffel implementor can:
  832.  
  833. -  bring Eiffel to the marketplace faster and at lower cost
  834. -  port their implementation more easily to other platforms
  835. -  take advantage of optimisation provided by the C compiler
  836.  
  837. Much of the technology that makes Eiffel relatively simple to use also 
  838. makes it more difficult to implement (an Eiffel-to-C compiler is 
  839. perhaps 4 to 5 times more difficult to create than a native Pascal 
  840. compiler).
  841.  
  842. Compiling Eiffel to C seems to work well under Unix. C is sometimes 
  843. thought of as the native code of Unix.
  844.  
  845. On the other hand, C is not universal on other platforms, and the 
  846. Eiffel purchaser may need to buy a C compiler as well, and possibly 
  847. replace it if the supported C compilers change with new versions of 
  848. the Eiffel compiler.
  849.  
  850. With a native-code compiler, you'd get somewhat better throughput and 
  851. the potential for smaller executables and slightly better performance. 
  852. You'd also get a higher price and an even longer wait for Eiffel to 
  853. show up on other than the leading market share machines.
  854.  
  855. ----------
  856.  
  857. L01)   What features does Eiffel have?
  858.  
  859. Eiffel is a pure object-oriented language. Its modularity is based on 
  860. classes. It stresses reliability, and facilitates design by contract. 
  861. It brings design and programming closer together. It encourages the 
  862. re-use of software components.
  863.  
  864. Eiffel offers classes, multiple inheritance, polymorphism, static 
  865. typing and dynamic binding, genericity (constrained and 
  866. unconstrained), a disciplined exception mechanism, systematic use of 
  867. assertions to promote programming by contract, and deferred classes 
  868. for high-level design and analysis.
  869.  
  870. Eiffel has an elegant design and programming style, and is easy to 
  871. learn.
  872.  
  873. An overview is available at 
  874. http://www.eiffel.com/doc/manuals/language/intro/
  875.  
  876. ----------
  877.  
  878. L02)   What changes have been made to the Eiffel language definition?
  879.  
  880. Eiffel is still a relatively new language, and there have been a 
  881. number of changes to its definition. Here is a summary of the major 
  882. changes:
  883.  
  884. 1. Changes between the publication of "Object-Oriented Software 
  885.    Construction" in 1988, and the release of Eiffel 2.3:
  886.  
  887.    - Constrained genericity enables a generic class to restrict its 
  888.      generic parameters to the descendants of a given class
  889.  
  890.    - The "indexing" clause allows information about a class to be 
  891.      recorded for extraction by archival, browsing and query tools
  892.  
  893.    - The assignment attempt operator "?=" provides a way to make 
  894.      type-safe assignments going against the inheritance hierarchy
  895.  
  896.    - User-defined infix and prefix operator features
  897.  
  898.    - Expanded types support composite objects without dynamic 
  899.      allocation, and with value semantics
  900.  
  901.    - The "obsolete" clause for smooth library evolution
  902.  
  903.    - The "unique" keyword for implicitly-assigned integer codes
  904.  
  905.    - The multi-branch instruction (similar to a case statement)
  906.  
  907.    - The boolean operator for implication ("implies")
  908.  
  909. 2. Changes with the introduction of Eiffel Version 3:
  910.  
  911.    - The feature adaptation subclause must now be terminated with 
  912.      "end"
  913.  
  914.    - Semicolons as instruction separators are optional
  915.  
  916.    - Groups of features are bracketed by a feature clause. All 
  917.      features are exported unless the feature clause specifies a 
  918.      restriction. The repeat subclause is no longer needed, because 
  919.      inherited features keep the original export status they had in 
  920.      the parent unless they are redefined, or are the subject of an 
  921.      export subclause in the feature adaptation clause.
  922.  
  923.    - Preconditions can only be replaced by weaker ones, postconditions 
  924.      can only be replaced by stronger ones. This is now enforced by 
  925.      the language through the use of "require else" in preconditions 
  926.      and "ensure then" in postconditions.
  927.  
  928.    - Ambiguities in repeated inheritance are resolved by a "select" 
  929.      clause.
  930.  
  931.    - A feature can no longer be replicated and redefined in the same 
  932.      feature adaptation clause, however the same effect can be 
  933.      achieved through repeated inheritance
  934.  
  935.    - Two or more features may be defined at the same time (e.g. "f1, 
  936.      f2 is...").
  937.  
  938.    - The keyword "frozen" before a feature name prohibits redefinition 
  939.      of the feature in descendants
  940.  
  941.    - In an anchored declaration, the anchor may now also be a formal 
  942.      argument of the enclosing routine
  943.  
  944.    - A class may have zero, one or more creation procedures, 
  945.      designated with the "creation" keyword. A new creation syntax 
  946.      using the "!!" symbol allows the appropriate creation procedure 
  947.      to be specified. It is also possible to directly create an object 
  948.      of any type which conforms to the entity to which it is being 
  949.      attached.
  950.  
  951.    - The meaning of dot notation has been made more uniform, and 
  952.      alternative constructs have been provided for the special 
  953.      language-defined features that previously used dot notation:
  954.          x.Create   is now  !! x
  955.          y.Clone(x) is now  y := clone(x)
  956.          x.Forget   is now  x := Void
  957.          x.Void     is now  x = Void
  958.          x.Equal(y) is now  equal(x, y)
  959.  
  960.    - Manifest arrays can be specified, for example
  961.          <<"Jan", "Feb", "Mar">>
  962.      which also provides a way to pass a variable number of arguments 
  963.      to a routine.
  964.  
  965.    - The command-line parameters are made available to the creation 
  966.      procedure of the root class as an array of strings.
  967.  
  968.    - A default rescue procedure called default_rescue may be defined 
  969.      and inherited.
  970.  
  971.    - A class may be declared to be an expanded class, in which case 
  972.      any type based on that class will be expanded.
  973.  
  974.    - An object may no longer contain a reference to an expanded object 
  975.      that is a sub-object of another object. Instead, upon assignment 
  976.      of an expanded object to a non-expanded object, the expanded 
  977.      object will be cloned, and a reference to the newly-cloned object 
  978.      will be stored in the non-expanded object.
  979.  
  980.    - The operator "div" has been replaced by "//", and the operator 
  981.      "mod" has been replaced by "\\".
  982.  
  983. 3. Changes between first and second printings of "Eiffel: The Language"
  984.  
  985.    - New basic types INTEGER_REF, REAL_REF, CHARACTER_REF and 
  986.      BOOLEAN_REF etc have been introduced to provide non-expanded 
  987.      basic types.
  988.  
  989.    - Introduction of the POINTER type to enable external references to 
  990.      be passed around in Eiffel programs.
  991.  
  992.    - Calls from Eiffel to external routines no longer implicitly pass 
  993.      the current object as the first parameter.
  994.  
  995.    There are many other (more minor) changes, which Neil Wilson has 
  996.    summarized in ftp.cm.cf.ac.uk:/pub/eiffel/Docs in both Microsoft 
  997.    Rich Text Format and ASCII.
  998.  
  999. ----------
  1000.  
  1001. L03)   What libraries come with Eiffel?
  1002.  
  1003. All vendors aim to support the Eiffel Library Standard kernel classes.
  1004.  
  1005. In addition, extensive library classes are supplied with the compilers 
  1006. including data structures, graphics, lexical analysis and parsing, IO, 
  1007. persistence, formatting and more.
  1008.  
  1009. Contact the vendors for further details.
  1010.  
  1011. ----------
  1012.  
  1013. L04)   What's the big deal about preconditions and postconditions?
  1014.  
  1015. The big deal is that it supports programming by contract. For example, 
  1016. preconditions (require clauses) are simple boolean statements that are 
  1017. used to check that the input arguments are valid and that the object 
  1018. is in a reasonable state to do the requested operation. If not, an 
  1019. exception is generated. Similarly, postconditions (ensure clauses) 
  1020. make sure that a method has successfully performed its duties, thus 
  1021. "fulfilling its contract" with the caller. Invariants are boolean 
  1022. expressions that are checked every time an object method returns back 
  1023. to a separate object.
  1024.  
  1025. You can use these ideas in any OO programming language, but usually 
  1026. must supply your own assertion mechanisms or rely on programmer 
  1027. discipline. In Eiffel, the ideas are integrated into the whole fabric 
  1028. of the environment. We find them used by:
  1029.  
  1030. -- the exception handling mechanism.
  1031.    (Tracebacks almost always identify the correct culprit code since 
  1032.    preconditions almost always denote an error in the calling method, 
  1033.    while postconditions denote an error in the called method.)
  1034.  
  1035. -- the automatic compilation system.
  1036.    (Assertions can be disabled entirely or selectively by type on a 
  1037.    per class basis.)
  1038.  
  1039. -- the Eiffel compiler
  1040.    (Invariants, preconditions and postconditions are all inherited in 
  1041.    a manner that makes logical sense.)
  1042.    (Assertion expressions are not allowed to produce side effects so 
  1043.    they can be omitted without effect.)
  1044.  
  1045. -- the automatic documentation tools
  1046.    (Preconditions and postconditions are important statements about 
  1047.    what a method does, often effectively describing the "contract" 
  1048.    between the caller and callee. Invariants can yield information 
  1049.    about legal states an object can have.)
  1050.  
  1051. In the future we expect to see formal methods technology work its way 
  1052. into the assertion capability. This will allow progressively more 
  1053. powerful constraints to be put into place. In addition, if a 
  1054. conjecture by Dr. Meyer bears fruit, the notion of preconditions may 
  1055. be extended into an important mechanism for the development of 
  1056. parallel programming.
  1057.  
  1058. ----------
  1059.  
  1060. L05)   Please explain and discuss covariance vs. contravariance.
  1061.  
  1062. Consider the following situation: we have two classes PARENT and 
  1063. CHILD. CHILD inherits from PARENT, and redefines PARENT's feature 
  1064. 'foo'.
  1065.  
  1066.    class PARENT
  1067.       feature
  1068.          foo (arg: A) is ...
  1069.    end
  1070.  
  1071.    class CHILD
  1072.       inherit
  1073.          PARENT redefine foo end
  1074.       feature
  1075.          foo (arg: B) is ...
  1076.    end
  1077.  
  1078. The question is: what restrictions are placed on the type of argument 
  1079. to 'foo', that is 'A' and 'B'? (If they are the same, there is no 
  1080. problem.)
  1081.  
  1082. Here are two possibilities:
  1083.  
  1084.    (1)  B must be a child of A (the covariant rule - so named because 
  1085.         in the child class the types of arguments in redefined 
  1086.         routines are children of types in the parent's routine, so the 
  1087.         inheritance "varies" for both in the same direction)
  1088.  
  1089.    (2)  B must be a parent of A (the contravariant rule)
  1090.  
  1091. Eiffel uses the covariant rule.
  1092.  
  1093. At first, the contravariant rule seems theoretically appealing. Recall 
  1094. that polymorphism means that an attribute can hold not only objects of 
  1095. its declared type, but also of any descendant (child) type. Dynamic 
  1096. binding means that a feature call on an attribute will trigger the 
  1097. corresponding feature call for the *actual* type of the object, which 
  1098. may be a descendant of the declared type of the attribute. With 
  1099. contravariance, we can assign an object of descendant type to an 
  1100. attribute, and all feature calls will still work because the 
  1101. descendant can cope with feature arguments at least as general as 
  1102. those of the ancestor. In fact, the descendant object is in every way 
  1103. also a fully-valid instance of the ancestor object: we are using 
  1104. inheritance to implement subtyping.
  1105.  
  1106. However, in programming real-world applications we frequently need to 
  1107. specialize related classes jointly.
  1108.  
  1109. Here is an example, where PLOT_3D inherits from PLOT, and 
  1110. DATA_SAMPLE_3D inherits from DATA_SAMPLE.
  1111.  
  1112.    class PLOT
  1113.       feature
  1114.          add(arg: DATA_SAMPLE) is ...
  1115.  
  1116.    class PLOT_3D
  1117.       inherit
  1118.          PLOT redefine add end
  1119.       feature
  1120.          add(arg: DATA_SAMPLE_3D) is ...
  1121.  
  1122. This requires the covariant rule, and works well in Eiffel.
  1123.  
  1124. It would fail if we were to put a PLOT_3D object into a PLOT attribute 
  1125. and try to add a DATA_SAMPLE to it. It fails because we have used 
  1126. inheritance to implement code re-use rather than subtyping, but have 
  1127. called a feature of the ancestor class on an object of the descendant 
  1128. class as if the descendant object were a true subtype. It is the 
  1129. compiler's job to detect and reject this error, to avoid the 
  1130. possibility of a run-time type error.
  1131.  
  1132. Here's another example where a real-world situation suggests a 
  1133. covariant solution. Herbivores eat plants. Cows are herbivores. Grass 
  1134. is a plant. Cows eat grass but not other plants.
  1135.  
  1136.    class HERBIVORE                               class PLANT
  1137.    feature
  1138.       eat(food: PLANT) is ...
  1139.       diet: LIST[PLANT]
  1140.  
  1141.    class COW                                     class GRASS
  1142.    inherit                                       inherit
  1143.       HERBIVORE                                     PLANT
  1144.          redefine eat
  1145.       end
  1146.    feature eat(food: GRASS) is ...
  1147.  
  1148. This does what we want. The compiler must stop us from putting a COW 
  1149. object into a HERBIVORE attribute and trying to feed it a PLANT, but 
  1150. we shouldn't be trying to do this anyway.
  1151.  
  1152. Also consider the container 'diet'. We are not forced to redefine this 
  1153. feature in descendant classes, because with covariant redefinition of 
  1154. the argument to 'eat', the feature 'diet' can always contain any 
  1155. object that can be eaten (e.g. grass for a cow). (With contravariant 
  1156. redefinition of the argument to 'eat', it would be necessary to 
  1157. re-open the parent class to make the type of the container 'diet' more 
  1158. general).
  1159.  
  1160. To summarise: Real-world problems often lend themselves to covariant 
  1161. solutions. Eiffel handles these well. Incorrect programs in the 
  1162. presence of covariant argument redefinition can cause run-time type 
  1163. errors unless the compiler catches these.
  1164.  
  1165. Sather uses the contravariant rule, but uses separate mechanisms for 
  1166. subtyping and code reuse and only allows dynamic binding on true 
  1167. subtypes. This seems to make contravariance work well, but it can 
  1168. force the Sather programmer to use concrete types when modelling 
  1169. covariant problems. Concrete types cannot be further subtyped in 
  1170. Sather, so this can reduce the potential for re-use (in Eiffel, any 
  1171. type can be further subtyped, but the compiler must check that it is 
  1172. used validly).
  1173.  
  1174. ----------
  1175.  
  1176. L06)   Is it true that there are "holes" in the Eiffel type system?
  1177.  
  1178. No. The design of Eiffel makes it possible to catch all type errors at 
  1179. compile time, so that an Eiffel program cannot abort with a run time 
  1180. type error.
  1181.  
  1182. However, to catch a class of certain more obscure type errors at 
  1183. compile time, the compiler must analyse the way that classes interact 
  1184. within the entire system, rather than just looking at each class one 
  1185. by one.
  1186.  
  1187. There is a proposal underway that, if accepted, will allow compilers 
  1188. to check this class of errors by looking at classes and not at the 
  1189. whole system.
  1190.  
  1191. Because system-wide compile-time validity checking can be complex, 
  1192. some compilers insert run-time traps for these errors instead, and 
  1193. some may fail to correctly trap these errors. Ask your Eiffel compiler 
  1194. vendor how they handle these type problems.
  1195.  
  1196. ----------
  1197.  
  1198. L07)   Is there support for concurrency in Eiffel?
  1199.  
  1200. Eiffel does not yet support concurrency; neither do current commercial 
  1201. compilers. However, work on concurrency for Eiffel is a hot research 
  1202. topic.
  1203.  
  1204. For four articles on concurrency facilities for Eiffel, including 
  1205. Bertrand Meyer's article "Systematic Concurrent Object-Oriented 
  1206. Programming", see the September 1993 "Communications of the ACM" (Vol. 
  1207. 36, Number 9).
  1208.  
  1209. At least one of these articles can also be obtained from ISE's WWW 
  1210. site (http://www.eiffel.com).
  1211.  
  1212. ----------
  1213.  
  1214. L08)   Why doesn't Eiffel allow function overloading?
  1215.  
  1216. In Eiffel, no two features of a class may have the same identifier, 
  1217. regardless of their respective signatures.  This prevents the use of 
  1218. function overloading ("multiple polymorphism"), a common programming 
  1219. technique in languages like C++.
  1220.  
  1221. Eiffel is designed to be minimal: it includes exactly the features 
  1222. that its designer considered necessary, and nothing else.
  1223.  
  1224. Because Eiffel already supports (single) polymorphism through its 
  1225. inheritance system, the only positive thing that function overloading 
  1226. buys you is reducing the number of feature names you have to learn. 
  1227. This is at the expense of reducing the ability of the compiler to trap 
  1228. mistakes (often type errors).
  1229.  
  1230. Readability is also enhanced when overloading is not possible. With 
  1231. overloading you would need to consider the type of the arguments as 
  1232. well as the type of the target before you can work out which feature 
  1233. is called. With multiple inheritance and dynamic binding this is 
  1234. awkward for a compiler and error-prone for a human. There is no 
  1235. intuitive rule which could be used to disambiguate routine calls where 
  1236. there is no "nearest" routine.
  1237.  
  1238. However, in Eiffel it's easy to write one routine with arguments of 
  1239. the most general applicable type, then use the assignment attempt 
  1240. operator to carry out the appropriate operation according to the 
  1241. run-time type of the arguments (thereby explicitly programming the 
  1242. disambiguation "rules").
  1243.  
  1244. Having said that, the lack of multiple polymorphism does force us to 
  1245. write some common mathematical operations (e.g. matrix math) in an 
  1246. awkward way, and forces arithmetic expressions to be treated specially 
  1247. (the "arithmetic balancing rule", ETL p385). But no-one has come up 
  1248. with a solution which is so simple, elegant and useful that it 
  1249. improves the quality of Eiffel as a whole.
  1250.  
  1251. ----------
  1252.  
  1253. L09)   Why are there no procedural types in Eiffel?
  1254.  
  1255. The notion of allowing a routine to be passed as an argument to a 
  1256. routine is in many people's view incompatible with the OO method. The 
  1257. definition of object-orientation implies that every operation belongs 
  1258. to an object type, so one does not manipulate routines just by 
  1259. themselves.
  1260.  
  1261. A possible technique when one feels the need to use a routine argument 
  1262. is to write a class and include the routine in it. Then (rather than 
  1263. passing a routine argument) pass an object - an instance of this class 
  1264. - to which the routine can then be applied. This is a more flexible 
  1265. approach in the long term. For example, you may later add an "undo" 
  1266. routine to your routine - containing class, or an attribute such as 
  1267. "time of last execution".
  1268.  
  1269. ----------
  1270.  
  1271. L10)   Why are there no class attributes in Eiffel?
  1272.  
  1273. In Eiffel, the "once" function provides greater functionality in a 
  1274. more disciplined way. The body of a "once" function is executed once 
  1275. only, when it is first called. Thereafter, the "once" function returns 
  1276. the same Result without re-executing its body.
  1277.  
  1278. The "once" function can therefore be used to implement a shared 
  1279. attribute of reference type (initialized on its first use).
  1280.  
  1281. A "once" function can be included in a mixin class. The shared 
  1282. attribute returned by that once function is then available to all 
  1283. instances of classes which inherit from the mixin class.
  1284.  
  1285. ----------
  1286.  
  1287. L11)   How can I call the parent-class version of a redefined routine?
  1288.  
  1289. When an inherited routine is redefined in a child class, is there a 
  1290. way for the redefined routine to call the version in the parent class?
  1291.  
  1292. 1) If you are responsible for the design of the parent class, you may 
  1293.    anticipate such a need. You may provide multiple versions of the 
  1294.    same routine body, with some versions frozen (not redefinable):
  1295.  
  1296.    class PARENT
  1297.    feature foo, frozen parent_foo is
  1298.       do
  1299.          ...
  1300.       end
  1301.    end
  1302.  
  1303.    class CHILD
  1304.    inherit
  1305.       PARENT
  1306.          redefine foo
  1307.       end
  1308.    feature foo is
  1309.       do
  1310.          parent_foo
  1311.          ...
  1312.       end
  1313.    end
  1314.  
  1315. 2) Otherwise, you use repeated inheritance to get two versions of 
  1316.    'foo', and redefine one of them:
  1317.  
  1318.    class PARENT
  1319.    feature foo is
  1320.       do
  1321.          ...
  1322.       end
  1323.    end
  1324.  
  1325.    class CHILD
  1326.    inherit
  1327.       PARENT
  1328.          rename foo as parent_foo
  1329.       end
  1330.       PARENT
  1331.          redefine foo
  1332.          select foo  -- (in case of dynamic binding)
  1333.       end
  1334.    feature
  1335.       foo is
  1336.          do
  1337.             parent_foo
  1338.             ...
  1339.          end
  1340.    end
  1341.  
  1342. ----------
  1343.  
  1344. L12)   Where can I find a comparison between Eiffel and C++?
  1345.  
  1346. In Richard Wiener's book "Software Development Using Eiffel: There can 
  1347. be life after C++" (Prentice-Hall, ISBN 0-13-100686-X).
  1348.  
  1349. ----------
  1350.  
  1351. L13)   Are there any destructors in Eiffel?
  1352.  
  1353. Eiffel objects are garbage-collected, so that there is no need for the 
  1354. software developer to worry about whether, how and when to "destruct" 
  1355. or "free" them in the software text.
  1356.  
  1357. Some implementations offer a "free" procedure for programmers who 
  1358. absolutely want to remove an object manually. Such a procedure is "use 
  1359. at your own risk" and is not needed in normal Eiffel development.
  1360.  
  1361. Coming back to normal usage, the need may arise to ensure that certain 
  1362. operations will automatically take place whenever the garbage 
  1363. collector reclaims an object. For example if an Eiffel object 
  1364. describing a file becomes unreachable and hence is eventually 
  1365. garbage-collected, you may want to ensure that the physical file will 
  1366. be closed at that time. Some implementations of Eiffel provide a 
  1367. mechanism for that purpose: procedure 'dispose' from the Kernel 
  1368. Library class MEMORY.
  1369.  
  1370. Whenever the garbage collector collects an object, it calls 'dispose' 
  1371. on that object. The procedure does nothing by default (so that a smart 
  1372. GC will of course avoid executing any actual call). But any class may 
  1373. inherit from MEMORY and redefine 'dispose' to perform appropriate 
  1374. actions, such as closing a file. Such actions are sometimes called 
  1375. "finalization". This technique achieves it conveniently.
  1376.  
  1377. Because there is no guarantee as to the order in which the garbage 
  1378. collector will reclaim objects that have become unreachable, safe 
  1379. redefinitions of 'dispose' should only act on external resources such 
  1380. as file descriptors, database elements, window system resources etc, 
  1381. not on Eiffel object structures themselves.
  1382.  
  1383.  
  1384. -- 
  1385. o          '''           Conrad Taylor                      o
  1386. o         (o o)          Software Engineer                  o
  1387. o-----oOO--(_)--OOo----- Land Mobile Products Sector        o
  1388. o  The Eiffel Language   conradt@comm.mot.com               o
  1389.